home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1597.txt < prev    next >
Text File  |  1997-04-01  |  17KB  |  452 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        Y. Rekhter
  8. Request for Comments: 1597       T.J. Watson Research Center, IBM Corp.
  9. Category: Informational                                    B. Moskowitz
  10.                                                          Chrysler Corp.
  11.                                                           D. Karrenberg
  12.                                                                RIPE NCC
  13.                                                             G. de Groot
  14.                                                                RIPE NCC
  15.                                                              March 1994
  16.  
  17.  
  18.                 Address Allocation for Private Internets
  19.  
  20. Status of this Memo
  21.  
  22.    This memo provides information for the Internet community.  This memo
  23.    does not specify an Internet standard of any kind.  Distribution of
  24.    this memo is unlimited.
  25.  
  26. 1. Introduction
  27.  
  28.    This RFC describes methods to preserve IP address space by not
  29.    allocating globally unique IP addresses to hosts private to an
  30.    enterprise while still permitting full network layer connectivity
  31.    between all hosts inside an enterprise as well as between all public
  32.    hosts of different enterprises. The authors hope, that using these
  33.    methods, significant savings can be made on allocating IP address
  34.    space.
  35.  
  36.    For the purposes of this memo, an enterprise is an entity
  37.    autonomously operating a network using TCP/IP and in particular
  38.    determining the addressing plan and address assignments within that
  39.    network.
  40.  
  41. 2. Motivation
  42.  
  43.    With the proliferation of TCP/IP technology worldwide, including
  44.    outside the Internet itself, an increasing number of non-connected
  45.    enterprises use this technology and its addressing capabilities for
  46.    sole intra-enterprise communications, without any intention to ever
  47.    directly connect to other enterprises or the Internet itself.
  48.  
  49.    The current practice is to assign globally unique addresses to all
  50.    hosts that use TCP/IP.  There is a growing concern that the finite IP
  51.    address space might become exhausted.  Therefore, the guidelines for
  52.    assigning IP address space have been tightened in recent years [1].
  53.    These rules are often more conservative than enterprises would like,
  54.    in order to implement and operate their networks.
  55.  
  56.  
  57.  
  58. Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 1]
  59.  
  60. RFC 1597        Address Allocation for Private Internets      March 1994
  61.  
  62.  
  63.    Hosts within enterprises that use IP can be partitioned into three
  64.    categories:
  65.  
  66.       - hosts that do not require access to hosts in other enterprises
  67.         or the Internet at large;
  68.  
  69.       - hosts that need access to a limited set of outside services
  70.         (e.g., E-mail, FTP, netnews, remote login) which can be handled
  71.         by application layer gateways;
  72.  
  73.       - hosts that need network layer access outside the enterprise
  74.         (provided via IP connectivity);
  75.  
  76.       - hosts within the first category may use IP addresses that are
  77.         unambiguous within an enterprise, but may be ambiguous between
  78.         enterprises.
  79.  
  80.    For many hosts in the second category an unrestricted external access
  81.    (provided via IP connectivity) may be unnecessary and even
  82.    undesirable for privacy/security reasons.  Just like hosts within the
  83.    first category, such hosts may use IP addresses that are unambiguous
  84.    within an enterprise, but may be ambiguous between enterprises.
  85.  
  86.    Only hosts in the last category require IP addresses that are
  87.    globally unambiguous.
  88.  
  89.    Many applications require connectivity only within one enterprise and
  90.    do not even need external connectivity for the majority of internal
  91.    hosts.  In larger enterprises it is often easy to identify a
  92.    substantial number of hosts using TCP/IP that do not need network
  93.    layer connectivity outside the enterprise.
  94.  
  95.    Some examples, where external connectivity might not be required,
  96.    are:
  97.  
  98.       - A large airport which has its arrival/departure displays
  99.         individually addressable via TCP/IP. It is very unlikely that
  100.         these displays need to be directly accessible from other
  101.          networks.
  102.  
  103.       - Large organisations like banks and retail chains are switching
  104.         to TCP/IP for their internal communication.  Large numbers of
  105.         local workstations like cash registers, money machines, and
  106.         equipment at clerical positions rarely need to have such
  107.         connectivity.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 2]
  115.  
  116. RFC 1597        Address Allocation for Private Internets      March 1994
  117.  
  118.  
  119.       - For security reasons, many enterprises use application layer
  120.         gateways (e.g., firewalls) to connect their internal network to
  121.         the Internet.  The internal network usually does not have direct
  122.         access to the Internet, thus only one or more firewall hosts are
  123.         visible from the Internet.  In this case, the internal network
  124.         can use non-unique IP numbers.
  125.  
  126.       - If two enterprises communicate over their own private link,
  127.         usually only a very limited set of hosts is mutually reachable
  128.         from the other enterprise over this link. Only those hosts need
  129.         globally unique IP numbers.
  130.  
  131.       - Interfaces of routers on an internal network usually do not
  132.         need to be directly accessible from outside the enterprise.
  133.  
  134. 3. Private Address Space
  135.  
  136.    The Internet Assigned Numbers Authority (IANA) has reserved the
  137.    following three blocks of the IP address space for private networks:
  138.  
  139.         10.0.0.0        -   10.255.255.255
  140.         172.16.0.0      -   172.31.255.255
  141.         192.168.0.0     -   192.168.255.255
  142.  
  143.    We will refer to the first block as "24-bit block", the second as
  144.    "20-bit block, and to the third as "16-bit" block.  Note that the
  145.    first block is nothing but a single class A network number, while the
  146.    second block is a set of 16 contiguous class B network numbers, and
  147.    third block is a set of 255 contiguous class C network numbers.
  148.  
  149.    An enterprise that decides to use IP addresses out of the address
  150.    space defined in this document can do so without any coordination
  151.    with IANA or an Internet registry.  The address space can thus be
  152.    used by many enterprises.  Addresses within this private address
  153.    space will only be unique within the enterprise.
  154.  
  155.    As before, any enterprise that needs globally unique address space is
  156.    required to obtain such addresses from an Internet registry.  An
  157.    enterprise that requests IP addresses for its external connectivity
  158.    will never be assigned addresses from the blocks defined above.
  159.  
  160.    In order to use private address space, an enterprise needs to
  161.    determine which hosts do not need to have network layer connectivity
  162.    outside the enterprise in the foreseeable future.  Such hosts will be
  163.    called private hosts, and will use the private address space defined
  164.    above.  Private hosts can communicate with all other hosts inside the
  165.    enterprise, both public and private.  However, they cannot have IP
  166.    connectivity to any external host.  While not having external network
  167.  
  168.  
  169.  
  170. Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 3]
  171.  
  172. RFC 1597        Address Allocation for Private Internets      March 1994
  173.  
  174.  
  175.    layer connectivity private hosts can still have access to external
  176.    services via application layer relays.
  177.  
  178.    All other hosts will be called public and will use globally unique
  179.    address space assigned by an Internet Registry.  Public hosts can
  180.    communicate with other hosts inside the enterprise both public and
  181.    private and can have IP connectivity to external public hosts.
  182.    Public hosts do not have connectivity to private hosts of other
  183.    enterprises.
  184.  
  185.    Moving a host from private to public or vice versa involves a change
  186.    of IP address.
  187.  
  188.    Because private addresses have no global meaning, routing information
  189.    about private networks shall not be propagated on inter-enterprise
  190.    links, and packets with private source or destination addresses
  191.    should not be forwarded across such links.  Routers in networks not
  192.    using private address space, especially those of Internet service
  193.    providers, are expected to be configured to reject (filter out)
  194.    routing information about private networks.  If such a router
  195.    receives such information the rejection shall not be treated as a
  196.    routing protocol error.
  197.  
  198.    Indirect references to such addresses should be contained within the
  199.    enterprise.  Prominent examples of such references are DNS Resource
  200.    Records and other information referring to internal private
  201.    addresses.  In particular, Internet service providers should take
  202.    measures to prevent such leakage.
  203.  
  204. 4. Advantages and Disadvantages of Using Private Address Space
  205.  
  206.    The obvious advantage of using private address space for the Internet
  207.    at large is to conserve the globally unique address space by not
  208.    using it where global uniqueness is not required.
  209.  
  210.    Enterprises themselves also enjoy a number of benefits from their
  211.    usage of private address space: They gain a lot of flexibility in
  212.    network design by having more address space at their disposal than
  213.    they could obtain from the globally unique pool.  This enables
  214.    operationally and administratively convenient addressing schemes as
  215.    well as easier growth paths.
  216.  
  217.    For a variety of reasons the Internet has already encountered
  218.    situations where an enterprise that has not between connected to the
  219.    Internet had used IP address space for its hosts without getting this
  220.    space assigned from the IANA.  In some cases this address space had
  221.    been already assigned to other enterprises.  When such an enterprise
  222.    later connects to the Internet, it could potentially create very
  223.  
  224.  
  225.  
  226. Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 4]
  227.  
  228. RFC 1597        Address Allocation for Private Internets      March 1994
  229.  
  230.  
  231.    serious problems, as IP routing cannot provide correct operations in
  232.    presence of ambiguous addressing.  Using private address space
  233.    provides a safe choice for such enterprises, avoiding clashes once
  234.    outside connectivity is needed.
  235.  
  236.    One could argue that the potential need for renumbering represents a
  237.    significant drawback of using the addresses out of the block
  238.    allocated for private internets.  However, we need to observe that
  239.    the need is only "potential", since many hosts may never move into
  240.    the third category, and an enterprise may never decide to
  241.    interconnect (at IP level) with another enterprise.
  242.  
  243.    But even if renumbering has to happen, we have to observe that with
  244.    Classless Inter-Domain Routing (CIDR) an enterprise that is connected
  245.    to the Internet may be encouraged to renumber its public hosts, as it
  246.    changes its Network Service Providers.  Thus renumbering is likely to
  247.    happen more often in the future, regardless of whether an enterprise
  248.    does or does not use the addresses out of the block allocated for
  249.    private networks.  Tools to facilitate renumbering (e.g., DHCP) would
  250.    certainly make it less of a concern.
  251.  
  252.    Also observe that the clear division of public and private hosts and
  253.    the resulting need to renumber makes uncontrolled outside
  254.    connectivity more difficult, so to some extend the need to renumber
  255.    could be viewed as an advantage.
  256.  
  257. 5. Operational Considerations
  258.  
  259.    A recommended strategy is to design the private part of the network
  260.    first and use private address space for all internal links.  Then
  261.    plan public subnets at the locations needed and design the external
  262.    connectivity.
  263.  
  264.    This design is not fixed permanently.  If a number of hosts require
  265.    to change status later this can be accomplished by renumbering only
  266.    the hosts involved and installing another physical subnet if
  267.    required.
  268.  
  269.    If a suitable subnetting scheme can be designed and is supported by
  270.    the equipment concerned, it is advisable to use the 24-bit block of
  271.    private address space and make an addressing plan with a good growth
  272.    path.  If subnetting is a problem, the 16-bit class C block, which
  273.    consists of 255 contiguous class C network numbers, can be used.
  274.  
  275.    Using multiple IP (sub)nets on the same physical medium has many
  276.    pitfalls. We recommend to avoid it unless the operational problems
  277.    are well understood and it is proven that all equipment supports this
  278.    properly.
  279.  
  280.  
  281.  
  282. Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 5]
  283.  
  284. RFC 1597        Address Allocation for Private Internets      March 1994
  285.  
  286.  
  287.    Moving a single host between private and public status will involve a
  288.    change of address and in most cases physical connectivity.  In
  289.    locations where such changes can be foreseen (machine rooms etc.)  it
  290.    may be advisable to configure separate physical media for public and
  291.    private subnets to facilitate such changes.
  292.  
  293.    Changing the status of all hosts on a whole (sub)network can be done
  294.    easily and without disruption for the enterprise network as a whole.
  295.    Consequently it is advisable to group hosts whose connectivity needs
  296.    might undergo similar changes in the future on their own subnets.
  297.  
  298.    It is strongly recommended that routers which connect enterprises to
  299.    external networks are set up with appropriate packet and routing
  300.    filters at both ends of the link in order to prevent packet and
  301.    routing information leakage.  An enterprise should also filter any
  302.    private networks from inbound routing information in order to protect
  303.    itself from ambiguous routing situations which can occur if routes to
  304.    the private address space point outside the enterprise.
  305.  
  306.    Groups of organisations which foresee a big need for mutual
  307.    communication can consider forming an enterprise by designing a
  308.    common addressing plan supported by the necessary organisational
  309.    arrangements like a registry.
  310.  
  311.    If two sites of the same enterprise need to be connected using an
  312.    external service provider, they can consider using an IP tunnel to
  313.    prevent packet leaks form the private network.
  314.  
  315.    A possible approach to avoid leaking of DNS RRs is to run two
  316.    nameservers, one external server authoritative for all globally
  317.    unique IP addresses of the enterprise and one internal nameserver
  318.    authoritative for all IP addresses of the enterprise, both public and
  319.    private.  In order to ensure consistency both these servers should be
  320.    configured from the same data of which the external nameserver only
  321.    receives a filtered version.
  322.  
  323.    The resolvers on all internal hosts, both public and private, query
  324.    only the internal nameserver.  The external server resolves queries
  325.    from resolvers outside the enterprise and is linked into the global
  326.    DNS.  The internal server forwards all queries for information
  327.    outside the enterprise to the external nameserver, so all internal
  328.    hosts can access the global DNS.  This ensures that information about
  329.    private hosts does not reach resolvers and nameservers outside the
  330.    enterprise.
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 6]
  339.  
  340. RFC 1597        Address Allocation for Private Internets      March 1994
  341.  
  342.  
  343. 6. References
  344.  
  345.    [1] Gerich, E., "Guidelines for Management of IP Address Space", RFC
  346.        1466, Merit Network, Inc., May 1993.
  347.  
  348. 7. Security Considerations
  349.  
  350.    While using private address space can improve security, it is not a
  351.    substitute for dedicated security measures.
  352.  
  353. 8. Conclusion
  354.  
  355.    With the described scheme many large enterprises will need only a
  356.    relatively small block of addresses from the globally unique IP
  357.    address space.  The Internet at large benefits through conservation
  358.    of globally unique address space which will effectively lengthen the
  359.    lifetime of the IP address space. The enterprises benefit from the
  360.    increased flexibility provided by a relatively large private address
  361.    space.
  362.  
  363. 9. Acknowledgments
  364.  
  365.    We would like to thank Tony Bates (RIPE NCC), Jordan Becker (ANS),
  366.    Hans-Werner Braun (SDSC), Ross Callon (Wellfleet), John Curran
  367.    (NEARNET), Vince Fuller (Barrnet), Tony Li (cisco Systems), Anne Lord
  368.    (RIPE NCC), Milo Medin (NSI), Marten Terpstra (RIPE NCC), and Geza
  369.    Turchanyi (RIPE NCC) for their review and constructive comments.
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 7]
  395.  
  396. RFC 1597        Address Allocation for Private Internets      March 1994
  397.  
  398.  
  399. 10. Authors' Addresses
  400.  
  401.    Yakov Rekhter
  402.    T.J. Watson Research Center, IBM Corp.
  403.    P.O. Box 218
  404.    Yorktown Heights, NY, 10598
  405.  
  406.    Phone: +1 914 945 3896
  407.    Fax: +1 914 945 2141
  408.    EMail: yakov@watson.ibm.com
  409.  
  410.  
  411.    Robert G Moskowitz
  412.    Chrysler Corporation
  413.    CIMS: 424-73-00
  414.    25999 Lawrence Ave
  415.    Center Line, MI 48015
  416.  
  417.    Phone: +1 810 758 8212
  418.    Fax: +1 810 758 8173
  419.    EMail: 3858921@mcimail.com
  420.  
  421.  
  422.    Daniel Karrenberg
  423.    RIPE Network Coordination Centre
  424.    Kruislaan 409
  425.    1098 SJ Amsterdam, the Netherlands
  426.  
  427.    Phone: +31 20 592 5065
  428.    Fax: +31 20 592 5090
  429.    EMail: Daniel.Karrenberg@ripe.net
  430.  
  431.  
  432.    Geert Jan de Groot
  433.    RIPE Network Coordination Centre
  434.    Kruislaan 409
  435.    1098 SJ Amsterdam, the Netherlands
  436.  
  437.    Phone: +31 20 592 5065
  438.    Fax: +31 20 592 5090
  439.    EMail: GeertJan.deGroot@ripe.net
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 8]
  451.  
  452.